(19) 



3 




(12) 



(43) Date of publication: 

17.03.1S99 Bulletin 1999/11 



Europdisches Patentamt 
European Patent Office 
Office europtendes brevets (H) EP 0 902 569 A1 

EUROPEAN PATE^^^ APPUCAtlQN 

(51) lnta;«: H04L 12/18 



(21) Application number: 98116496.5 

(22) Date of filing: 01.09.1998 



(84) Designated Contracting States: 

ATBECHCYDE DKES R FRGBGRIEITULU 
MCNLPTSE 

Designated Extension States: 
ALLTLVMKRpSi 

(30) Priority: 11.09.1^7 US 927426 

(71) Applicant AT&T Corp! 

New Yoric, NY 10013-2412 (US) 



(72) Inventors: 

• Shur, David Hilton 
MIddietown, New Jersey 07748 (US) 

• Zelezrriak, Atexandr 
Matawan, New Jersey 07747 (US) 

(74) Representative: 

Modiano, Guido, Dr.-lng. et ai 
liAodlano, Josif, Pisanty & Staub, 
Baaderstrasse3 
80469 MGnchen (DE) 



(54) Method and system for a unlcast endpoint client to access a multicast internet protQcol (ip) 
session 



(57) Unicast enc^pornt clients (110, 11 1 . 1 1 5) on an 
IP Unicast network (107. 108) are provided access to 
Multicast sessions on an IP Multicast network (101) 
through a Muiticast-Unicast gateway server (120, 121). 
The sender obtains information about sessions on the 
Multicast network and makes such information availatDle 
to a Unicast client on the Unicast network upon request 
by the client Upon beirtg presented with a list describ- 
ing the subject matter of each session, the user at the 
Unicast client selects the session to which he or she 
wants to join, which causes the Muiticast-Unicast server 
to join the appropriate session on behalf of the request- 
ing client for each media type in which the joining dient 
wants to be a participant The server then sets a bi- 
directional Unicast User Datagram Protocol (UDP) 

FIG, r 



stream between rtself and the client. All packets then 
received by the server from the Unicast client are 
address-translated to the appropriate Multicast session 
address. In addition, all packets received by the server 
on the Multicast session address are address-trans- 
lated and sent to the Unicast client The Unicast client is 
then able to participate in the Multicast session as both 
a sender and a receiver of packets to and from other 
Unicast and Multicast clients which are active during the 
session. Further, the Unicast client is capable of aeat- 
ing a new session, recording a session in the networtt 
for later retrieval and playback, and creating and 
accessing low barKiwidth versions of existing sessions. 
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Description 
Technical Fleid 

[0001] This invention relates to data convnunications. s 
and more particularly, to providing a Unicast endjxrint 
client on a Unicast network with the ability to access a 
Multicast session on an Multicast network. 

Background of the Invention ro 

[0002] In conventional packet, frame or cell based 
systems there are typically two modes of communica- 
tion: point-to-point (also known as Unicast) arid polnt-to- 
muft^nt (also known as MulticasQ. Multicast is 
addresses typk^ally differ from Unic^ addresses in thai 
they refer to an intermediate abstraction known as a 
group. All senders address their transmitted infonnation 
to this group and all receivers are luned" to "listen" to 
that address to receive the information transmitted to 20 
that group by the senders. The senders of information 
are thus effectiyety de-coupled from the set of receivers. 
Senders do not need to knew who the receivers are - 
they simply transmit packets addressed to the group 
Similarly, receivers do not need to know who the send- 2S 
ers are - they simply send a request to the network 
(routers) to join a spedfid group of interest 
[0003] Multimedia distribution and conferencing/col- 
laboration systems are advantageously and efficiently 
supported by Multicast communication methods. As will 30 
be used herein, a specific Multicast communication is 
referred to as a session. In the prior art, it is not posst>le 
for Unicast endpoints to access Multicast sessions, due 
to the differences in addressing modes and receiving 
modes. Thjs disadvantageously limits the ability of a 35 
user at a Unicast endpoint client to participate in ses- 
sions in which they have interest and in which they 
couki be an active participant 

Sumrnaryofthe Invention 40 

[0004] In accordance with the present invention, Uni- 
cast endpoint clients are enabled to access f/lulticast 
sessions. Furthermore, in accordance with the present 
inventions, Unicast endpoint clients are enabled to 45 
request network-based recording systems perform 
recordings of the Multicast session on behalf of clients. 
Even furthernrx)re, in addition to LAN attached end- 
points, analog dial-up (e.g.. 28.8 kbps) as wefl as ISDN 
Unicast endpoints are enabled to access appropriately so 
barKlwkith-reduced versiais of nominally high t>and- 
width sessions. 

[0005] Inter-connectivity between a Unicast client con- 
nected to a Unicast nehwork and one or more Multicast 
clients connected to a Multicast network is effected ss 
through a Multicast-Unicast Sender (MUS), in accord- 
ance with the present invention. Such a server obtains 
information about sessions on the Multicast network 



and makes such information available I0 the Unicast ci- 
ent on the Unicast network upon request by the cEerit. 
Upon being presented with a list descra^ng the subject 
matter of each sesston. the at the Unkast dient 
selects the sesdon to which he or she wants to join, 
which causes the Multicast-Unicast server to join the 
appropriate session on behalf of the requ^ng dient 
for each media type for whk:h the joining dient wants to 
be a partidpant. The server then sets a bi-directk)nal 
Unicast User Datagram Protocol (UDP) stream 
between itself and the client All packets then received 
by the server from the Unicast dient are address-trans- 
lated to the appropriate Multicast session address, fan 
addition, all packets received by the server on the Multi- 
cast session address are address-translated and sent 
to the Unkast dient The Unicast dient is then able to 
partidpate in the Multicast sesston as both a sender 
and a receiver of packets to and from other Unicast arxi 
Multk:ast dients which are active during the session. 
Firther, such a Unicast client if authentk»ted to do so, 
is capable of creating a new session, arid of recording a 
sessbn in the network for later retrieval and playback 
Firthermore. transcoding and rate adaptirig gateways 
are deployed within the Multicast networic that map 
existing sessions into low t^andwidth versions. If the 
Unicast client is a dial-up user connected to the Uncast 
networic over analog or ISDN ^dlities, these rate-con- 
trolled sessions can then be accessed by the dial-up 
users. 

Brief Description of the Drawings 
[0006] 

FIG. 1 is a block diagram showing Unicast dients 
conneded on a Unicast Intemet Prolocd (IP) net- 
wtk accessing an IP Multicast networt^ through 
Multicast-Unicast Servers (MUS's); 
FIG 2 is a block diagram of a MUS; 
FIG. 3 shows the software components of a client 
terminal that enable the dient to access a Multk:ast 
session; 

FIG. 4 is a flowchart detailing the steps assodated 
with a Unicast dient joining a Multicast session on 
the Multicast network; 

FIG. 5 is a flowchart detailing the steps of a Unicast 
dient creating a Multicast session; 
FIG. 6 is a f bwchart detailing the ^eps of a Unk:ast 
dient recording a Multicast session; and 
FIGS. 7A and 78 together detail the steps of a Uni- 
cast dient rate-adapting/transcoding a Multk:ast 
session. 

Detailed Description 

[0007] With reference to FIG. 1 , an IP Multicast net- 
work 1 01 is shown induding, as way of illustration, three . 
interconnected Multicast Routers (MR) 102-1, 102-2. 
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and 102-3. A well known cuaently in place IP Multicast 
network is the so-called MBONE (Multk^st BacMdone), 
which te a pdtiic shared IP Multicast network spanning 
many countries and covering thousands of IP sub-net- 
works, tn addition to the MBONE, numerous private 
Intranets also use Multicast IP for intra-corporate com- 
munications. A pluraltty of multimedia dient terminals 
are connected to IP Multicast network 101. for example 
the MBONE. For way of illustration only, in FIG. 1 two 
client terminals 103 arii 104 are shown connected to 
network 101 through respective Local Area Networks 
(LANs) 105 and 106, respectively. Each LAN is con- 
nected through a customer premises router (not shown) 
over, for example, a T1 line. Frame Relay (FR), ATM, or 
an X.25 connection. In accordance with Multicast com- 
nruintcation, a sender of information of a particular 
media type transmits packets of information to a partic- 
ular address, which are then automatically distritxited to 
each of the members of a group that have requested to 
receive from that address. Advartageously, the netwtvlc 
peHbrms the replication furictions necessary so that 
each receiver cfient of the group can reoeive the pack- 
ed transmitted to the address ksy a sender or senders. 
[0008] In accordance wHh the present invention, Unt- 
cast client terminals connected to a Unicast IP network 
is capable of joining in and participating with a Multicast 
session on an IP Multicast networic FIG. 1 shows two 
Unicast IP networks t07 and 108. Illustrative Unicast 
dient terminals 1 lO ahd 1 11 are connected to network 

107 through conventional Unicast Routers (URs) 112 
and 113, respectively. Unicast client terminal 1 1 5 is con- 
nected to UR 116 within network 108. URIIGin tumis 
shown connected to another UR. UR 117 for exanrple. 
which in turn is connected to UR 118. Networks 107 and 

1 08 are shown as being interconnected through U R 1 1 2 
and 118, thus enabling Ura'cast IP communication 
between a client terminal connected to Unicast IP net- 
wori^ 107and a client terminal connected to Unicast IP 
networt^ 108. The Unicast dient terminals 1 10, 1 1 1 and 
115, for exanple, can be connected to netwprt^ 107 or 
108 over a Plain Old Telephone Service (POTS) dial-up 
connection, an ISDN connection or an Asynchronous 
Digital Sut>5crfoer Loop (ADSL) connection, each to a 
Local Exchange Canier (LEC) (not shown) and from 
there to an Internet Service Provider (ISP) (not shown), 
which in tum is connected to the Unicast IP network 
through a Unicast Router. Alternatively, a client terminal 
can be connected to an ISP through a cable modem 
over cable fadlities through a cable TV provider, Even 
furtiier, the Unicast dient terminal could be connected 
to a LAN and to a customer premises router to a UR 
over, for example, a Wide Area Network (WAN). T1 fadl- 
ities, Frame Relay ATM. or X.25. In accordance with 
this invention. Unicast dient terminals 1 10. 1 1 1 , 1 1 5. for 
example, on Unicast IP networks 107 and 108. can par- 
ticipate in a Multicast IP session on IP Multicast network 
101. SpecHicalty, such functionality is enabled tiirough 
Mutticast-Unicast Serv&s (MUS's), such as MUS 120 in 



nehwork 107 and MUS 121 in network 108, wHch each 
interconnect tiieir respective Unicast IP networks 107 
and 108. withthe IP Multicast Metwortt 101. 
[0009] The Multicast-Unfoast Servers 120 and 121 

5 function as gateways that enatrie tfiose Untcast-con* 
nected dients on their respective Unicast IP networks to 
access IP Multicast network 101. Specifically, each 
MUS through interaction with dient software on the Uni- 
cast client on the Unicast IP network enables sudi dient 

10 to join a group on the IP Multicast network by providing 
infonnation relating to what sessfons are in progress or 
scheduled on network 101. The MUS th^ receives and 
sends data on those groups within a session selected 
l3y dient on t>ehalf of the dient Thus, the MUS functions 

75 to convert the address of the Multicast IP packets of a 
requested-fbr group to the Unicast IP end^point address 
of the requesting dient Furthermore, the MUS func- 
tions to transmit packets it receives from the Unicast 
endpoint dient to a list of any other Unk^ast endpoint 

so receivers for the requested-for Multicast group on the 
same Unicast IP network or an interconnected Unicast 
IP network (107 or 108), as well as to the Multicast 
group address itself on the IP Multicast network 101 to 
enable the Multicast endpoints, 103 and 104, for eicam- 

25 pie. connected on that network to receivia packets orijgfi- 
r^ng from the Unicast dient 
[0010] FIGS. 2 and 3 are block diagrams of an MUS 
201 and a dient terminal 301. respectively, showing 
their functions that enatile Ht&n to qperate in adcord- 

30 ance with the present invention. In FIG. -2 a Session 
Description Protocol (SDP) listener process 202 cou- 
pled to ttie IP Multicast network 101 listens for session 
announcements transmitted on Multicast network 101. 
Such directory announcements are repeatedly sent 

35 over the IP Multicast network 101. Th^e "advertised" 
sessions are received by tiie SDP/SAP advertised proc- 
ess; 203 and stored in a sessions database 204. Other 
sessions that are not announced and thus not received 
by the SDP listener process 202, are entered by a sys- 

40 tem administrator through a static sessions process 205 
and also stored in sessions datatDase 204. An example 
of the latter might be a weather channel that is always 
present on a predetermined socket and is not repeat- 
edly announced over the IP Multicast network 101 . 

45 [0011] An HTTP server 206 can read the sessions 
database 204 so that when a client connects to the 
server, tiie dient is able to receive a listing of those Mul- 
ticast sessions presently on the IP Multicast network 
101. When the client connects; to the server 206, tiie 

so server executes a CGI (Common Gateway Interface) 
scripts 207 within the HTTP server 206 on behalf of the 
dient to present the information pertaining to the ses- 
sions to the client Such information is presented t>ack 
to tiie dient 301 (FIG. 3) through its web browser pro- 

55 gram 302 (in FIG. 3). The diertt initiates a request to join 
a session by sheeting a URL on an HTML web page 
presented to it by HTTP server 206. A message is thus 
sent from the dient 301 by web browser 302, which 
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when received by server HTTP 206 causes it to invoke 
certain actions. Specificaily, HTTP server 206 sencte a 
response back to the cGent comprising a control mes- 
sage containing intomiation irdicating what tool needs 
to be used in order to join the selected session. Such 5 
tools are well known in the art and may include, for 
example, the Visual Audio Too! (VAT), the Visual Confer- 
ence Tool (Vip), or the Intemet Protocol Television Tool 
(IPTV). Furthermore, the message indicates where the 
tools should be connected, i.e.. specrically, to which w 
socket on the MUS the tool shouki be connected. On 
the client side, the client 301 then launches from launch 
program 303 the specified tool from tool program 304 to 
the indicated sockets on the MUS 201 . CGI scripts pro- 
gram 207 then initiates the translation^^ack^-forwaix^ 15 
ing server 208 within MUS 201 to join the requested 
Multicast groxp or groups (one group per selected 
media type) associated with the selected session. CGI 
sopts 207 that initiated such join action to take place 
then adds that dienfs Unicast address to a list of receiv- so 
ers for the requested Multicast group or groups. Server 
208 then fbnvards Multicast packets received from the 
client to the list of receivers for each joined group and 
translates the Multicast address of packets received 
from the joined group to the Unicast address of the join- 25 
ingdient 

[001 21 The steps associated with a client joining a 
session are detailed with reference to the fJowchart In 
FIG. 4. At step 401. the SDP listener process accumu- 
lates IP Multicast network 101 directory announce- 30 
ments into database 204. The database is filtered and 
converted into a standard HTML page, where each U RL 
points to information pertaining to each Multicast ses- 
sion in the filtered database. At step 402, the HTTP 
sender 206 listens for requests for Multicast ses- 35 
sions/URLs on the HTML page wtiich contains a list of 
URLs describing the sessions. At step 403, a request is 
received froni a cTient for a copy of the page containing 
the Multicast sessions. At step 404, the HTTP server 
206 sends a message back to the client requesting the 40 
user enter a login id and a password for authentication 
purposes. If the user is successfully authenticated at 
step 405, at step 406. server 206 returns a page to the 
client containing a list of sessions. When, at step 407. 
the user of the dient browses tiie page and requests a 45 
session indicated by a URL, at step 408. server 206 
returns a page containing details of the session and but- 
tons enabling the client to request the session to start 
as well as otiier functions to be descn'bed later herein. 
At st^ 409. the client starts a selected session (or spe- so 
cif ic media in the session) by '^Dressing" a button on the 
HTML page. The server 206 then launches a control 
script 207. At step 410, the control script 207 sends a 
respcsise to the client containing information about 
which multimedia tool to launch, and what UDP sockets 55 
(the Unicast IP address on tine MUS and associated 
ports) to listen to and to send information to corresporKl- 
ing to the requested group. It can be assumed that at 



least one socket is used, A second socket may be used 
to send controi^tatus information from each member of 
the Multicast group. At step 41 1 . the same control script 
207 of server 206 cause$ the Mutticast-to Unicast gate^ 
way to join the requested-fcN^ Multicast group and adds 
tfie requesting cfient to the list of receivers tor the 
requested for Multicast group. For each requesting c&-^ 
ent. sender 206 also converts the address of the Multi- 
cast IP packets of the requested-for group to the 
Unicast IP address of the requesting dient and sends 
the Unicast IP packets to the requesting client using the 
well-known User Datagram Protocol (UDP). Server 206 
also ti^ansmits arry packets it receives from the client to 
any other Unicast client on that Multicast group, as well 
as to the Multicast group acidress itself on the IP Multi- 
cast network 101. At step 412. when the cfient exits 
from the multimedia tod. server 206 detects that status 
messages from tiie dient are no fonger being sent and 
removes tiie dient from the list of destinatfons for the 
partk^ular Multicast group. 

[0013] The steps assodated with a dient creating a 
hew session are detaDed In RG. 5. At step 501 . as pre- 
viously descrft>ed in connection with the steps in FK3. 4 
associated v«th a dient jdning a session, tiro SDP lis- 
tener process 202 accumulates IP Multicast network 
101 directory announcements into database 204. The 
database is filtered and converted into a standard 
HTML page, where each URL points to infonmation per- 
taining to each Multicast session in tiie Jittered data- 
base At step 502. tiie HTTP server 206 listens for 
requests for Multicast sessfons/URLs on the HTML 
page which contains a list of URLs describing tiie ses- 
sions. When a user of a dient requests a copy of the 
page containing the Multicast sessions at step 503, tiie 
server 206. at step 504, sends a message back to tiie 
dient requesting a login id and password for authentica- 
tion purposes. If autiientication is successful at step 
505. at step 506. server 206 returns a page to tiie dient 
containing a list of sessions. When tiie user browses 
tiiat page and requests a specific URL., senrer 206. at 
step 507. returns a page containing details of the ses- 
sion arKJ txittons enafc)ling the dient to request a sessfon 
to start, to create a new session, to edit or delete an 
existing session, and to record ttie cun-ent session, tfie 
later functionality to be descrtoed hereinafter. When, at 
step 508, tiie user "presses" a button to create a new 
session, at step 509. server 206 returns a form to tiie 
dient requesting tfie client to enter a login id and pass- 
word appropriate for creating a new session, which may 
or may not be the same as the togin id and password 
associated with tiie initial authentication process. If, at 
step 510. ttie dient is autheiticated for session aea- 
tion. sender 206 retorns at step 51 1 a form to the dient 
wrtii fields to be filled in by ttie user for the session 
name, session description, a URL address for more 
detailed or related information., a field to set the Multi- 
cast packet Time to Live value (TTL), selection boxes for 
various media tods, and assodated coding formats. 
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Midticast addresses and ports to use, the name and 
phone number of a responsble person, and the Mira- 
tion of the session announcement. When the user fills in 
the fields and selects a aeate txittori, the filed-in form 
is returned to the server 206l Server 2C^ checks thai 
certain key fields are correct and filled in. If not an error 
message is returned to the client; otherwise server 206 
stores the data in a file that is indexied to the login id 
used to access the form. The data, at slep 512. is then 
made availat)te to a Session Announcement Protocol 
(SAP) process 210 on MUS 201. Al step 513. the SAP 
process 210 periodically announces the sessk>n onto a 
well-knowim f^ulticast IP address ^nd port reserved for 
such announcements for a period of tmrie equal to the 
duration fieW as entered in the form. When tliis time 
period expires, the SAP process 210 ce^es to 
announce the session. 

[0014] A Unicast endpoint can also, in accordance 
with the present invention. Tequest that a sesston be 
recorded for later rebroadcast or retrieval oh derhand. 
To effect such rec6rd|ing, m FIGi 1. a recorder 125 is 
connected via LAN 126 to the IP Multicast network 101. 
The flowchart in FIG, 6 details the steps associated with 
a user at a dient terminal requesting that a session be 
recorded. As described previously, the client must be 
given a login id and password to enable access to the 
HTTP server 206 which has a list of the IP Mu!tica$t 
sessions. At step 601. the SDP listener process 202 
accumulates IP Multicast rietwork 101 directory 
announcements into sessions database 204. Tbe data- 
base is filtered and converted into a standard HTML 
page, where each URL points to information pertaining 
to each Multicaist session in the filtered database. At 
step 602. server 206 listens for requests for Multicast 
sessions/URLs on the HTML page which contains a list 
of URLs desCTibing the sessions. When, at step 603. a 
user requests a copy of the page containing the Multi- 
cast sessions, at step 604. server 206 sends a message 
back to the client requesting his or her login id and pass- 
word for authentication purposes. If, at step 605. 
authentication is successful, at step 606. server 206 
returns a page to the client containing a list of sessions. 
When a user browses that page and requests a URL. 
server 206. at step 607, returns a page containing 
details of the session, and buttons enabling the dient to 
request a session, to start the existing session, to cre- 
ate a new session, to edit or delete an existing session, 
or to record the cun-errt session. At step 608, the user 
"presses" a button to record a session and, at step 609. 
server 206 returns a form to the cFient requesting the 
user to enter a login id and password for recording pur- 
poses, which may or may not be the same as the login 
id and password used in a previous step. If. at st^ 610, 
the dient is authenticated for session recording, server 
206 retums a form to the dient witb fields to be filled in 
or options to be selected. The form contains selection . 
boxes for the various media of the session, and start 
and stop date ard time fields, as weD as a start button to 



"push" when the form is complete. When the user fills in 
the fields and selects the start form, the filled-in form is 
returned to server 20a Server 206 checks that certain 
key fieMs are correct and filled in. If not, an error mes- 

5 sage is returned to the dient; otherwfee the serveir 
stores the data in a file that is indexed to the togin kl 
used to access the form. At step 6.1 1 . server 206 sends 
a message to the recording server 125 to start the 
recording at the specified date and time. The recording 

]o server 1 25. at step 61 2. then records the session at the 
appropriate time using a well-knowri program for read- 
ing IP Multicast packets in the RTP formal At step 613, 
the stored session is retrieved on-deinand 1^ the user. 
[00151 To support dial-up Urocast endpdnt users, 

15 prior art transcocfing aiid rate ad^ng gateways, such 
as transcoder/adapter 127 in FIGL 1, are deptoyed 
witf^n IP Multicast network 101. As shown in FIGL 1, 
transcoder/rate adapter gateway 127 is connected via 
LAN 128 to the IP Multfoast networic 101. Attematively, 

20 transcoder/rate adapter gateway 127 may be co-resi- 
dent with either MUiS 120 or 121. The gat^y maps 
e)dsb'ng high t>adidwidth sessions into lew bandwktth 
versions of |he sarrie session surte^e for 2a8 kbps 
modems oi- ISDN adapters by using frame discarding 

25 algorithma Announcernents about these rate-controlled 
sessions are then placed in the datat>ase of IP Multfoast 
nelwortc 101 sessiidins. : , 

[0016] An altemative rneditanisiriri for irri/okjrig the 
transcoding/rate adapting gatew^ could' b<a biksid bn 

30 user/di^ action. The steps astsod^ed with' a dfent 
requesting that a session be automatically trans- 
coded/rate adapted are detaHed in FIGS. 7A and 7B. As 
described previously, the user of the dient must be 
given a login \6 and a password to enattle access to 

35 HTTP server 206. As described previously, at step 701 , 
the SDP listener process 202 accumulates IP Multicast 
nehwork 101 directory announcements into database 
204. The database is fetered and converted into a 
standard HTML page, where each URL points to inforr 

40 mation pertaining to each Multicast session the fatered 
databasa It is assumed that a required bandwklth 
parameter and maximum packet loss parameter are 
assodated with each session. For sessfons using a 
fonm as prevfously descrit>ed. this is accomplished by 

45 the use of additional fiekJs corresponcfing 1o these 
parameters in the "new sessiori" form descrtoed herein- 
above. At slep 702. HTTP server 206 listens for 
requests for Multicast sessions/URLs on ttie HTML 
page containing a list of URLS describir^ the sessions. 

50 When, at step 703. a request is received from a dient for 
a copy of the page containing the Multicast sessions, at 
step 704. server 206 sends a message back to the di- 
ent requesting a login id and password for authentica- 
tion purposes. If. at step 705. authentication is 

55 successful, at step 706, server 206 retums a page to 
the client containing a list of sessions. When after tiie 
user browses the page, and at step 707. selects a ses- 
don and group(s) within a sessfon, server 206. at step 
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708, returns a page containing details of the session 
and tHittons enabling the client to request a session to 
start, to creates new sessbn. to edit or delete an exist- 
ing sessioa or to record the current session. At step 

709, the user pushes a button to r^uest the session or 5 
specific mec£a in the session to start In response 
thereta at step 710, server 206 launches a control 
scrpt which sends a series of test packets to the dienl 

At step 711, the client echoes these same packets back 
to the server 206. At step 712, the server conrputes an 10 
estimate of the available bandwidth and packet toss 
along the path between the sender and the client by 
comparing the transmitted test packets with the 
received test packets. If , at decision step 713, the per- 
formance requrements of the session exceed that of 75 
the path, at step 714, rate-adaptation or transcoding is 
needed. If not, the process continues as previously 
descrit>ed for a client joining an existing session. If rate 
adaptation or transcodng is needed, at step 715, one 
out of plurality of lower rate encocfin^ is selected based go 
on the measured qharacteristics of the path. It is to t>e 
assumed that a finite set of rate adapted sessions are 
allowed by the sender 206. As an example, if the ori^hal 
session was 128 kbps, rate adaptation to 56 1^, 28.8 
kbps and 20 kbps may be airowed. At step 716, HTTP ss 
server 206 sends a message to the transcoding/rate 
adapting gateway 127 indicating which Multicasft group 
is to be joined, to what bandv^ ttie media-type should 
be rate-adapted, what (if any) alternative coding needs 
to applied, and what new Multicast address and port 30 
nurrb& the transcoded session should use. At step 

717, a determination is made whether that group has 
already be^ rate-adapledftranscoded. If yes, at step 

718, the Multlcasl address and port numl>er conre- 
sponding to the already rate-adapted/transcoded group 35 
is used and the process proceeds to step 719. If no, at 
step 720, the transcoder/rate adapter gateway 127 is 
Invoked to transcode the session with appropriate band- 
width parameters and to re-f^ulticast the resulting 
lower-bandwidth session using a different Multicast 40 
address and port number. At step 719. the server 206 
sends a message to the client containing information 
about which multimedia tool to launch, and what UDP 
sockets (the Unicast IP address on the MUS and asso- 
ciated ports) to listen to and to send information to cor- 45 
responding to tiie requested session. At step 721. the 
control-script causes the MUS gateway to join the 
requested Multicast group and add the requesting client 

to the list of receivers for requested Multicast, group. For 
each requesting client tiie server converts tiie address 50 
of the Multicast IP packets of the requested-for group to 
the Unicast IP address ol the requesting diertt. and 
sends the Unicast IP packets to tfie requesting client 
using the well-known User Datagram Protocol. TTie 
serve- also transmits any packets it receives from the 55 
<A\&il to ttie list of receivers for that Multicast group, as 
well as to the Muttic^ group address itself. At step 722. 
v\rhen the client exits the multimeclia tod, the HTTP 



serveir 206 detects that status messages trom the dient 
are no longer being sent and removes the client froni 
the list of destinations for the particular Multicast group. 
[0017] The system descrbed hereinaboye is highly 
scaleable in that the MUS and other servers may be ds- 
trbuted throughout the Multicast-enabled portion of the 
network. If the number of such endpoints is likely to be 
large, for efficiency, it \s preferred ttiat the servers be 
located dose to the Unicast dient enc^Doints. For small 
conferendng grpup, the locatk>n or distribution of the 
MUS*s is not important Advantageously, the present 
invention enables any IP Multicast-based service to t>e 
gradually introduced and rolled out on a small scale 
before all dients are enabled for IP Multicast. As dients 
become IP Multicast enabled, there could be a transi- 
tion to a hytxid IP Multicast mode of operation where 
some clients are IP Multicast connected and otiiers are 
rrot 

[0018] Although described in connection with Unicast 
IP end^ints; connecting to an IP Multicast network 101 
such as the MBONE, ttie present invention could jt>e 
emptoyed with any IP Multicast network Further the 
present invention coukJ be enployed with any Multicast 
network and Unicast network that operate In a similar 
fashion to IP Multicast and Unicast networks. 
[0019] The above-descrOsed entxxiiments are flius* 
trative of the prindples of the present inventipri. Other 
embodiments coukJ be devised by thpse skilled in t[ie 
art witiiout departing from the spirit and scope of the 
present invention. 

[0020] Where technical features mentioned in ariy 
daim are followed by reference signs, those reference 
signs have been induded for the sole purpose of 
increasing the intelligibOity of tiie daims and accordingly 
such reference signs do not have any limiting ^fect on 
the scope of each element identified by way of example - 
by such reference signs. 

Qalms 

1 . A method of providing access to a Multicast session 
on a Multicast network to a Urilcast cGent on a Uni- 
cast netvrork comprising: 

accumulating at a gateway server Interconnect- 
ing the Multicast network and the Unicast net- 
work directory information relating to Multicast 
sessions on the Multicast network; 
supplying the Unicast dient with the directory 
information accumulated by the gateway 
server; 

recaving at the gatew^ server from the Uni- 
cast dient a request to join a selected session 
chosen from the directory information ; 
joining the requ^ed-for Multicast session at 
the gateway server on tDehalf of ttie Unkast cG- 
ent; 

converting at the gateway server an address of 
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Multicast packets rectived on a Multicast 
address associated with the requested-for ses- 
sion to a Unicast address of the Unicast diarrt 
and sending «ie Mulficast packets r^c^ed t>/ 
the gateway server on the Multicast address to 5 
the Urecast client; iand 

tran^ratfing packets recdved at the gateway 
server from the Unicast client to the Multicast 
address associated with the requested-for ses- 
sion. ^0 

2. The method of daim 1 wherein the request to join a 
Multicast session is a request to Join at least one 
group of a plurality of groups associated with the 
Multicast session, each of said plurality of groups is 
having an associated Multicast address. 

3. The method of daim 2 wherein eadi of said at least 
one group is assodated with a different media type. 

; 20 

4. The method of daim 1 further comprising before 
supplying the Unicast dient with thie cfirectory infor- 
mation, authenticatingthe Unicast dient 

5. The method of claim 4 wherein the authenticating 25 
corrprises receiving at the gateway server a logn 
identity and a password from the Unicast diertt^ 

6. The method of daim 1 wherein the Unicast and - 
Multicast networks are IP ^Internet ProtocoO Uni- so 
cast and IP Multicast networks, respectively. 

7. The method of claim 6 wherein pad^ets are trans- 
mitted between the gateway server and the Unicast 
dient using the User Datagram Protocol. 55 

8. The method of daim 6 wherein the directory infor- 
mation comprises an HTML page having a plurality 
of URLs each pointing to informatkin assodated 
with a Multicaist session on the. IP Multicast net- 40 
work. 

9. The method of daim 6 wherein the IP Multicast net- 
work is the MBONE. 

.45 

10. A method of creating a Multicast session on a Mul- 
ticast networit by a Unicast dient on a Unicast net- 
wortt conprising: 

accumulating at a gateway server interconnect- so 
ing the Multicast network and the Unicast net- 
work directory information relating to Multicast 
sessions on the Multicast network; 
supplying the Unicast drent with the directory 
information acciimdaled by the gateway ss 
sender; 

receiving a request at the gateway server from 
the Unica^ dient to create a Multicast session; 



receving and storing at the gateway server 
information about the MuKxast session: and 
announdng the Multfoast session by the gate- 
way servisr onto the Multicast networit onto a 
predetemrtined Multicast address for such 
announceni^its. 

11. The method of daim 10 wherein the Untoast and 
Multicast networks are IP (Internet Protocol) Uni- 
cast and IP Multicast networi<s. respectively. 

12. The method of claim 10 wherein the session is 
announced periodically onto the Muttfoast networic 

13. The method of 10 further comprising before supply- 
ing the Unicast dient with the directory information, 
authenticating the Unicast dienl 

14. The method of daim 13 further comprising after 
receiving a reque&t at the gateway server from the 
Unicast dient to aeate a session, authentioating 
the Unicast dient to aeate a sessioa 

ISA method of recording a Multicast session on a Mul- 
tfoast network t)y a Unicast client on a Unicast net- 
work cortprising: 

accumulating at a gateway server interconnect- 
ing the Multicast netwOTk and the Unicast net- 
wort^ directory information relating to Multicast 
sessions on the Multicast network; 
supptyirig the Unicast client with the diredory 
information accumulated by the gateway 
server; 

recaving a request at the gateway server from 
the Unicast dient to record a selected Multicast 
session, chosen from the directory information; 
and 

sencfing a message containing information 
about the selected Multicast session from the 
gateway server to a recording server con- 
nected to the Mutticasl network to record the 
selected session. 

16. The method of claim 15 wherein the Unicast net- 
viork and the Multicast networi^ are IP (Intemet Pro- 
tocol) Unicast and IP Multicast networi©. 
respectively. 

17. The method of daim 15 further comprising receiv- 
ing at the gateway server from the Unicast dient 
information about the selected Multicast session 
induding when to start and stop recording. 

ia The method of daim 17 wherein the information 
received at the gateway server from the Unicast di- 
ent further indudes an identification of spedfk; 
media to record of the seleded Multicast session. 
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19. The mjsthod of daim 15 further comprising before 
supplying the Urecast client with the directory infor- 
mation, authenticating the Unicast client 

20. The method of claim 19 further comprising after s 
receiving a request at the gateway server from the 
Unicast client to record a session, authenticating 
the Unicast client to record a session. 

21 . The method of claim 1 5 further comprising: w 

receiving a request at the gateway server from 
the Unicast client to access the recorded ses- 
sion; 

sending a message to the recorcfing server 75 
from the gateway server to the recording server 
to retrieve the recorded session; 
receiving the recorded session at the gateway 
server: and 

sending the recorded session from the gateway 20 
server to the Unicast client 

22. A method of providing access to a Multicast session 
on a Multicast netvtfork to a Unicast client on a Uni- 
cast network comprising 25 

accumulating at a gateway server interconnect- '. 
ing the Multicast network and the Unicast net- ~ 
work directory information relating to Multicast 
sessions on the Multicast network, the direc- so 
tory information including for each seission a 
Muttk;ast address for the session and a 
required bandwidth of ttie session; 
supplying the Unicast client with the directory 
information accumulated by the gateway 35 
server; 

receiving at the gateway server from the Uni- 
cast dient a request to join a selected session 
chosen frorri the directory infonnation; 
determining an estimate of the available band- 40 
width between the gateway server and the Uni- 
cast cGent; 

if the estimate of the availat)le bandwidth is less 
than the required bandwidtii tor the selected 
session, selecting a coding rate lower than a 45 
cocfing rate associated with the selected ses- 
sion; 

sending a message from the gateway server to 
a transcoding server connected to the Multicast 
network to rate-adapt the coding rate associ- so 
ated with the selected session to the selected 
lower cocfing rate; 

receiving at the gateway server from the trans- 
coding server an indication of the Multicast 
address to which the rate-adapted sheeted 55 
session is being transmitted; 
joining the rate-adapted sessk)n on behalf of 
the Unicast client at ttie gateway server on the 



incEcated Multicast address to which the rate- 
adapted selected session is being transmitted; 
converting at the gateway server the address of 
the Multicast packets received on the Multicast 
address to which the rate-adapted selected 
session being transmitted to a Unicast 
address of the Unic^ client and sending the 
Multicast packets received t>y the gateway 
server on ttiat Multicast address to the Unicast 
client and 

transmitting packets received at the gateway 
server from tiie Unicast client to ttie Multicast 
address to whteh the rate-adapted selected 
sessfon is transmitted. 

2a. The method of claim 22 wherein the Unicast and 
Multicast networks are IP (Intern^ Protocol) Uni- 
cast networi® and IP Multicast networks, respec- 
tively. 

24. The method of d^m 22 wherein tiie naquest to join 
a Multicast sessfon is a request to join at least one 
group of a plurality of groups associated with tine 
Multicast session, each of said plurality of groups 
having an associated Multicast address. 

25. The method of daim 24 wherein each of said plural- 
ity of groups is associated wttii a different media 
type. 

26. The method of daim 22 wherein determining an 
estimate of the available bandwidtfi comprises: 

transmitting a series of test packets to the Uni- 
castdient; 

receiving an echo of these test-packets b^ck 

from the Unicast dient 

and 

comparing the transmitted series of test-pack- 
ets with the received echo of these test pack- 
ets. 

27. A Multicast-Unicast server comprising: 

means for accumulating from a connected-to 
Multicast network directory information relating 
to Multicast sessions on tiie Multicast network; 
means for receiving from a Unicast dient on a 
Unicast network connected to tiie server a 
request to join a Multicast session from among 
the sessions accumulated in tiie directory infor- 
mation; 

means for joining tiie requested-for Multicast 
session on behalf of the dient; and 
means for converting ttie ^lutticast address of 
the Multicast packets on the requested-for Muf- 
. ticast sessfon to a Unicast address assoctated 
with tiie Unicast dient and for sending the Mul- 
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ticast packets on the requested-for Multic^ 
session to the Unicasl client at that Unicast 
acklress. and for sending packets received from 
*ie Unicast client to the Multicast address 
associated with the selected sessioa s 

28. The server of ciaim 27 wherein the Multicast net- 
work and the Unicast network the server is con- 
nected to are an IP (Internet Protocol) Multicast 
network and an IP Unicasl network, respectively. 

29. The server of claim 28 wherein packets are trans- 
mitied between the sen/er and the Unicast client 
using the User Datagram Protocol. 

30. The server ol daim 27 wherein the request to join a 
Multicast session is a request to join at least one 
group of a plurality of groups associated with the 
Multicast session, each of pluraBty of groups having 
an associated Multicast address. 

31. The server of claim 30 wherein each of sakJ plural- 
ity of g'OLips is associated with a different mecfia 
type. 

32. The server of clairn 27 wherein the means for con- 
verting also sencte packets received frbm^ the Uni- 
cast client to another Unicast client associated with 
the server and whic^i said another client is also con- 
nected to ttie sessiori. 



35 



40 



45 



SO 



55 



15 



20 



25 



30 



EP0902569A1 



EP 0 902 569 A1 



FIG. 2 



206 
-V- 



hhp server 
PjcrTpts] 



207 



i 



201 



MULTICAST-UNICAST SERVER 
203 




202 



SAP/SOP 
ADVERTISED 



STATIC 
SESSIONS 



T 

205 



204 



SOP 
LISTENER 
PROCESS 



^sSiSiSs 

DATABASE 



SAP 
ANNOUNCER 
PROCESS 

210 



TO 
MUUCAST 
NETVVORK 



I 
I 
I 

L *J 



1 



20B 



MUin-UNICAST , 
ADDRESS TRANSUnON 
AND PACKET 
FORWARDING 



FIG, 3 




EP0 902 569A1 



FIG. 4 



401 



( START ) 



402 



SDP USTENER PROCESS ACCUMUUTES 
MBONE DIRECTORY ANNOUNCEMENTS 
INTO DATABA SE 

♦ — 



HHP SERVER U STENS FOR REQUESTS 
I 



IS REQUEST RECEI VED 



> 



NO 



]m SERVER SENDS AUTHENTICATION REQUEST 



AUTHENTICAHON SUCCESSFUL ?. > 
HI 



NO 



406 



407- 



408' 



409 



410 



RETURN HTML PAGE CONTAINING 
SESSION LISTIN G 

3^ 



CUENT SELECTS SESSION AND 
GROUP WITHIN SESSION" 

I 



RETURN NEW PAGE CONTAINING SESSION 
PAGE AND C ONTROL BUHONS 
I 



CUENT STARTS SESSION BY 
PUSHING BUnON(s) 

t 



411 



HTTP SERVER SENDS CONTROL MESSAGE 
TO CUENT TO INFORM CUENT HOW TO 
SEND/RECEIVE INFORMATION TO 
GROUP(s ) SELECTED 

I 



412 



HTTP SERVER CAUSES MULTICAST-UNICAST 
ADDRESS TRANSLATOR TO JOIN THE 
REQUESTED GROUP(s) AND TO SEND 
INFORMATION TO CUENT; TRANSUTES 
MULTICAST ADDRESS OF GROUP TO 
UNICAST ADDRESS OF CLlF NT 

f ■ — 



WHEN CUENT QUITS. HHP SERVER 
REMOVES CUENT FROM UST OF 
DESTINATIONS FOR THAT PARTICULAR GROUP 



( END ) 



EP0 902569A1 



FIG. 5 



501 f 



502 
505 

504 



SDP USTENER PROCESS ACCUMUUTES MBONE DIRECTORY 
ANNOUNCEMENTS INtO DATABASE . 

\ 



HHP SERVER USTENS FOR REOUESTS 



< ^ IS REQUEST RECEIVED ? 

{YES 



HTTP SERVER SENDS AUTHENTIC ATION REQUEST 
" ^ ♦ 



505 __ : _ NO 



"-< f~~ AUTHENHCATION SUCCESSFUL ? , > 
506 jYES 



507 



RETURN. HTML PAGE, C0NTAMN6 SESSION OTG | 
-z: 



508 ^—( 

509 



RETURN PAGE CONTAINING SESSION PAGE AND BUTTONS ENABUNG 
SESSION TO START, CREA TE NEW SESSION. RECORD SESSION 



USER SELECTS TO CREATE NEW SESSION 
i ~~ 



RETURN FORM TO CLIENT REQUESTING LOGIN ID AND 
PASSWORD TO CREATE NEW SESSION 

I 



^ NO 

'"^ — AUIHLNIItAllUN mCESSFUL ? S >- 

♦ YES 

511 



512 



RETURN FORM TO CLIENT WITH HEIOS FOR SESSION NAME. 
DESCRIPTION, MULTICAST TTL VALUE, SELECTION OF MEDIA 
TOOLS, CODING FORMATS, MULTICAST ADDRESSES 
AND PORTS TO USE, ETC. 

♦ 



513 



IF APPROVED, DATA MADE AVAIUBLE TO SESSION 
ANNOUNCEMENT PROCESS (SAP) ON SERVER 

I 



SAP PERIODICALLY ANNOUNCES SESSION ONTO MULTICAST 
IP ADDRESS AND POR T RESERVED FOR SUCH ANNOUNCEMENTS 

— ^ ~ 

( END ^ — 



EP 0 902 569 A1 



FIG. 6 ClrARD 



SDP aSTENER PROCESS ACCUMUUTES MBONE DIRECTORY I ^601 
ANNOUNCEMENTS INTO DATABASE ^ 



602 \ 



604 



: HHP SERVER USTENS FOR REQUESTS 

603 t 

IS REQUEST RECEIVED ? > 
{YES 



NO 



HTTP SERVER SENDS AUTHENnCATION REQUEST 



606 



605 ♦ ~ 
""^ C AUTHENTICATION SUCCESSFUL ? 
JYES 



607 



608 



RETURN PAGE CONTAINING SESSION USTING 
T 



RETURN PAGE CONTAINING SESSION PAGE AND BUHONS ENABLING 
SESSION TO START. CREATE NEW S ESSION. RECORD SESSION 



USER SELECTS TO RECORD A SESSION 
^ \ 

609 



610 



RETURN FORM TO CUENT REQUESTING LOGIN ID AND 
PASSWORD TO RECORD A SESSION 

E 



AUTHENTICATION SUCCESSFUL ? > 



NO. 



611 



612 



Fyes" 



RETURN FORM TO CLIENT WITH RELDS TO IDENTIFY SESSION 
TO BE RECORDED, VARIOUS MEDIA OF SESSION. START 
AND STOP DATE AND TIME 

I 



613 



SERVER SENDS MESSAGE TO RECORDING SERVER TO START 
RECORDING SERVER AT SPECIHED DATE AND TIME AND TO 
STOP AT SPECinED DATE AND TIME 

I 



SERVER RECORDS SESSION USING PROGRAM FOR READING IP 
MULTICAST PACKETS IN THE RTP FORMAT . 



614 



JL 



STORED SESSION RETRIEVED ON DEMAND BY CUENT 
( END ) ■ 



EP0 902 569A1 



FIG. 7 A 

701 



( START ) 



SDP USTENER PROCESS ACCUMUUTES MBONE DIRECTORY 
ANNOUNCEMENTS INTO DATABASE 



702 
703 



♦ 



HHP SERVER USTENS FO R REQUESTS 
— ♦ 



704v-j2~ 
705v-^ 



IS REQUEST RECEIVED ? 
I YES 



> 



NO 



HHP SERVER SENDS AUTHENTICAHON REQUEST 
I 



706 



AUTHEHTICMIOH SnCCESSFUL ? 



>1!2-<D 



TO ncJB 



707 



RETURN HTML RAGE CONTAININ G SESSION UST1N6 



708 



CLIENT SELECTS SESSION A ND GROUP WITHIN SESSION 
~" ♦ 



RETURN NEW PAGE CONTAINING SESSION PAGE AND CONTROL BUTTONS 
FOR STARHNG SESSION/CREATING NEW SESSION. EDITING OR 
DELETING SESSION. RECORDING SESSION 



709 



T 



CLIENT STARTS SESSION BY PUSHING BUHON TO REQUEST 

SESSION OR SPE CIFIC MEDIA IN SESSION TO START 
: ♦ 



710> 
711 
712^ 



SERVER LUNCHES A CONTROL SCRIPT WHICH SENDS SERIES 

OF T EST PACKETS TO CUENT 
t 



CLIENT ECHOES TEST PACKETS BACK TO SERVER 
■ ~f " 



SERVER COMPUTES ESTIMATES OF AVAILABLE BANDWIDTH 
AND PACKET LOSS 



TO n6.7B 



EP0 902 569A1 



FIG. 7B 



FROM nCJA 




DOES PERFORMANCE REQUIREMENTS OF 
SESSION EXCEED THAT OF PATH ? 

♦ YES ~ 



713 



> 



NO 



RATE ADAPTATION OR TRANSCODING NEEDED 
I 



SELECT ONE OUT OF A PLURALITY OF LOWE R RATE ENCODINGS K" 

T — ' 



7U 



715 



HHP SERVER SENDS MESSAGE TO TRANSCODING GATEWAY 
INDICAnNG MULTICAST GROUP TO JOIN, TO WHAT BANDWIDTH 
THE MEDIA TYPE SHOULD BE RATE-ADAPTED, WHAT ALTERNATIVE 
CODING TO EMPLOY, AND WHAT NEW MULHCAST ADDRESS 
AND PORT NUMBER THE TRANS CODED SESSION SHOULD USE 

I 



716 



< GROUP ALREADY RATE-ADAPTED/TRANSCODEDI 

/" iio' 

r/ 



717- 



720 

A 



> 



YES 



718 



USE MULTICAST ADDRESS AND PORT NUMBER 

CORRESPONDING TO ALREADY RATE-ADAPTED/ 
" TRANSCODED GROUP ' 



TRANSCODING GATEWAY INVOKES TRANSCODER WITH BANDWIDTH 
PARAMETERS AND RE-MULTICASTS THE RESULTING LOWER-BANDWIDTH 
SESSION USING DIFFERENT MULTICAST ADDRESS AND PORT NUMBER 



I 



SEND CLIENT MESSAGE CONTAINING INFORMATION ABOUT WHAT 
MULTIMEDIA TOOL TO LAUNCH, WHAT UDP SOCKETS TO LISTEN 
TO AND TO SEND INFORMAHON TO FOR REQUESTED SESSION 

' — r — — 



-719 



MULnCAST-TO-UNICAST GATEWAY JOINS REQUESTED MULHCAST 
GROUP AND ADDS REQUESHNG CLIENT TO LIST OF RECEIVERS 

FOR REQUESTED MULTICAST GROUP; 
SERVER CONVERTS ADDRESS OF MULHCAST IP PACKETS OF 
REQUESTED GROUP TO UNICAST IP ADDRESS OF REQUESnNG 
CLIENT AND SENDS UNICAST IP PACKETS TO REQUESHNG CLIENT 
USING UDP AND TRANSMITS PACKETS FROM CUENT TO UST OF 
RECEIVERS FOR THAT MULTICAST GROUP AND TO MULTICAST GROUP 

T 



■721 



WHEN CLIENT QUITS. HTTP SERVER REMOVES CUENT FROM UST 
OF DESHNATIO NS FOR THE PARTICULAR MULTICAST GROUP 

I 



/722 • 
FROM nG.7A 



( END > 



EP 0902 569 A1 




European Patent 
Office 



EUROPEAN SEARCH REPORT 



Application ttumter 

EP 98 11 6496 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Citation pt document with indicatton. wtiere appropriate, 
of ratevam passapes 



Retevant 
to cfatfn 



CLASSIFlCA-nON OF tViE 
APPLICATION (IntCljS) 



PJAHANDARI K ; STERNE D E : . "An MBone 
proxy for an application gateway firewall 

PROCEEDINGS. 1997 IEEE SYMPOSIUM ON 
SECURITY AND PRIVACY (CAT. 
N0.97CB36097),May 1997, pages 72-81, 
XP002088643 
Oakland. CA, USA 

* page 72, left-hand column, line 1 - page 
73, left-hand column, line 28 * 

* page 73, right-hand colionn, line 48-51 * 

* page 75. right-hand column, line 28-43 ♦ 

* page 76, right-hand column, line 6 - 
page 78, right-hand column, line 29 * 

* figures 2,3 * 

CHERITON D R ET AL: "HOST GROUPS: A 
MULTICAST EXTENSION FOR DATAGRAM 
INTERNETWORKS" 

HIGH PERFORMANCE LIGHT-WEIGHT FUEL CELL 
ELECTRODES. 10 September 1985, pages 
172-179, XP0Op560608 

* page 173, left-hand column, line 22 - 
right-hand colunm, line 51 * 

* page 174, left-hand column, line 25-46 * 

* page 174, right-hand column, line 28 - 
page 175, right-hand coluiim, line 62 ♦ 

* page 176, left-hand column, line 20-26 * 



1.10.15. 
22,27 



H04L12/18 



1.10,15, 
22.27 



TECHNICAL RELDS 
SEMCHEO (ltitCU> 



H04L 



The presem seardi report has been drawn up tor an ctaitns 



PUe«otm(ch 

THE HAGUE 



Diti 01 compMon ol iht sufCh 

11 January 1999 



LI evens, K 



CATEGORY OF CITED DOCUMENTS 

X : partjoiarty rBtovam tftaton stm 

Y : particUarty relsvafit a comtunod wth anolher 

doomnt ol thQ MnwcatBgoiy 
A : t»e*vtalbgfetl baek^wnd 
O: nofHRrrtsen tfbdoftm 
P: intsnrndtatedOQimenl 



T : theory or principM unaartying lh» inventior 
E : etrf&f patont documort bU p^fished on. or 

after the filing dM» 
0 : doouman ened in (tw ■ppfictUorV 
L : document dtadfor othar reasons 

a : member erf thasampatarttenfly.oon^s^^ 



EP0 902 569A1 



J) 



European Patent 
Offica 



EUROPEAN SEARCH REPORT 



CP 9S 11 6496 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Citation ot document wsn tncflcaion. wrere approprtaie, 
01 relevant passapcs 



tpcialni 



CLASSIFtCATION OF THE 
fcPPUCATtOH (tatCU) 



HUGHES L: "GATEWAY DESIGNS FOR 

INTERNETWORK MULTICAST COMMUNICATION" 

COMPUTER COMMUNICATIONS, 

vol. 12, no. 3, June 1989, pages 123-130. 

XP000033075 

* page 123, left-hand column, line 1 - 
page 124, left-hand column, line 29 ♦ 

* page 124, right-hand column, Tine 5 
page 125, left-hand column, line 20 * 

* page 125, left-hand coluinn, line 55 - 
right-hand column, line 15 * 

* page 126, right-hand column, line 26-36 

* . ■ 

* page 128, left-hand column, line 8-28 ♦ 

HOLFELDER U : "Interactive remote 
recording and playback of imjlticast 
videoconferences" 

INTERACTIVE DISTRIBUTED fWLTIHEOIA SYSTEMS 
AND TELECOMMUNICATION SERVICES. 4TH 
INTERNATIONAL WORKSHOP, IDMS '97, 
10 September 1997, pages 450-463, 
XP002088645 
Darmstadt, Germany 

* abstract * 

* page 450, line 13-16 * 

* page 451, line 14 - page 452, line 5 * 

* page 454, line 1-33 * 



1.10,15, 
22,27 



The present search report has been d/swn up for aD ctaims 



15 



TECHNICAL FIELDS 
SEARCHED (lrtLa.%) 



Ptac«e4s*tKti 

THE HAGUE 



Oatt ot oornptttoi ot tt« SMich 

11 January 1999 



Eismntr 

L1 evens, K 



CATEGORY OF QTEO OOCUWENTS 



X :pan)cui«iy retovam i tatctn aiono 

Y :paftlcultfVrof«vantVcon)t>MwtthBnothv 

documsrtt of th* same caioooiy 
A : te ct in ctloip iu lbacfcyound 
O : nofHvrtltn tfsctosuv _ 
P ' kiterniecflato tUxsunwt' 



T : th«ofyorpffincpteuid»flyingth»lfw«ntioA 
E: eora«rp«tertdoeumonl.butpubllsttoden, or 

«n«rth» filing 
D : documoft ct*d (n m* appBcoUon 
•L : document CM IX ctrwr reasons 



a : merrtMr of tte %tam pataft! famOy. comspendtrg 
docmwnt 



This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record 

BEST AVAILABLE IMAGES 

Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 

□ BLACK BORDERS 

□ IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 
^ FADED TEXT OR DRAWING 

□ BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 

□ LINES OR MARKS ON ORIGINAL DOCUMENT 

□ REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: . 

IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



